Method for testing non-deterministic device data

ABSTRACT

A method for testing semiconductor devices that output non-deterministic entity information such as packet and control signals is disclosed. The method includes the steps generating test signals with a semiconductor tester and applying the generated test signals to the device-under-test. Actual output entities from the DUT in response to the applied generated test signals are captured by the tester and compared to expected output entities. If a failure is identified in the comparing step, the method defines a window of valid expected entities and compares the failed actual output entity to the window of valid expected entities. If a match occurs between the failed actual output entity and any of the expected entities in the window, the actual entity is deemed valid.

RELATED APPLICATIONS

This Application is a Continuation of application Ser. No. 10/606,848filed on Jun. 26, 2003 incorporated herein by reference.

FIELD OF THE INVENTION

The invention relates generally to automatic test equipment, and moreparticularly to a method for enabling the testing of non-deterministicsemiconductor device data.

BACKGROUND OF THE INVENTION

Test is an important step in the manufacture of semiconductor devices.The automatic test equipment (ATE), or testers, employed to carry outthis task comprises sophisticated electronics capable of sending testsignals to, and capturing output signals from, one or more devices undertest (DUTs). ATE software often helps to orchestrate this back and forthflow of signals.

Conventional testers, as shown in FIG. 1, feed tester data signals(drive data) originating from a pattern generator 12 to adevice-under-test (DUT) 14 via interface circuitry commonly referred toas pin electronics 16. Response signals from the DUT are captured andcompared to expected data with the resulting comparison data fed to afailure processor 18 in order to determine pass or fail conditions. The“expected” and “drive” data are typically programmed in the patterngenerator vector memory (not shown) to occur at precise timings, inaccordance with how the DUT should behave. If the data captured from theDUT fails to correspond with an expected condition, the device isconsidered to have failed that aspect of the test.

Modern semiconductor devices are trending towards employing multipleprocessing cores on the same piece of silicon, or chip. Adding to thiscomplexity is the overall trend towards implementing on-chipcommunication protocols including, for example, Rapid I/O,Hypertransport, and specialized bus architectures such as DDR and sourcesynchronous, etc. The end result is an exponential increase in the chipgate count, yet only modest increases in the available pin counts.Consequently, multiple sub-circuits often share the pins (interface).

This shared interface scheme is illustrated generally in FIG. 2, where aplurality of device-under-test subcircuits 20 a-20 c send data packetsto a DUT communications port 22. The communications port serves as thegatekeeper to accessing the DUT output pin 24. Each of the subcircuitsmay be clocked by a separate clock having a frequency different from notonly the other subcircuits, but also possibly different from thecommunications port clock. An asynchronous arbitrator 26 handles thesequencing of the data packets to the DUT output pin.

During typical DUT operation, as shown in FIG. 3, the shared interfacescheme may cause a problem (for conventional ATE) known as “out-of-orderdata”. This situation often results from the subcircuits attempting toaccess the communications port 22 (FIG. 2) on the same clock edge, orhaving differing delays due to environmental conditions. FIG. 3illustrates the general concept on how an expected sequencing may bedisturbed into an out-of-order packet sequence. The “out of order” dataproblem presents a unique challenge to automatic test equipment, whichis conventionally dependent on deterministic data from the DUT.

What is desired and currently unavailable is a test solution fornon-deterministic data that provides substantially real-time validationresults and maximizes flexibility for the device manufacturer whilereducing test costs. The apparatus and method of the present inventionprovides such a solution.

SUMMARY OF THE INVENTION

The present invention provides the ability for automatic test equipmentto quickly validate non-deterministic data, such as “out of order” datareceived from a device-under-test. This ability is available with littleto no impact to the automatic test equipment hardware, and isuniversally applicable to many protocols. With the availability of sucha solution, users of the automatic test equipment will experiencesignificant test throughput improvements and reduced test costs.

To realize the foregoing advantages, the invention in one form comprisesa method for testing semiconductor devices that output non-deterministicentity information such as packet and control signals. The methodincludes the steps generating test signals with a semiconductor testerand applying the generated test signals to the device-under-test. Actualoutput entities from the DUT in response to the applied generated testsignals are captured by the tester and compared to expected outputentities. If a failure is identified in the comparing step, the methoddefines a window of valid expected entities and compares the failedactual output entity to the window of valid expected entities. If amatch occurs between the failed actual output entity and any of theexpected entities in the window, the actual entity is deemed valid.

Other features and advantages of the present invention will be apparentfrom the following detailed description when read in conjunction withthe accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be better understood by reference to the followingmore detailed description and accompanying drawings in which

FIG. 1 is a high-level block diagram of a conventional ATE architecturefor driving data to a DUT and comparing the DUT response data toexpected data;

FIG. 2 is a high-level block diagram of a DUT output interfacearchitecture;

FIG. 3 is a block diagram illustrating the out of order problemresulting from the DUT output scheme of FIG. 2;

FIG. 4 is an elevated perspective view of a semiconductor testeremploying the method of the present invention;

FIG. 5 is a flowchart illustrating steps included in one form of thepresent invention;

FIG. 6 is a flowchart illustrating more specific steps for the comparestep of FIG. 5; and

FIG. 7 is a graphical representation of a valid entity window inaccordance with the method shown in FIG. 5.

DETAILED DESCRIPTION OF THE INVENTION

The present invention provides a way to test semiconductor devices thatemploy communications protocol ports that often generatenon-deterministic output data exhibiting out-of-order results. This isaccomplished through the use of automatic test equipment 30 (FIG. 4)that employs software utilizing a unique method of analyzing andprocessing the non-deterministic data for a determination of datavalidity.

Referring now to FIG. 4, the automatic test equipment 30, often referredto as a semiconductor tester, includes a main frame 32 coupled to atesthead 34. The testhead houses the various instruments desired by theuser to adequately test a device-under-test DUT 40. The instrumentsgenerally comprise large circuit boards, or channel cards, that mountwithin the testhead in order to interface with the DUT in a controlledfashion. The channel cards include the hardware resources that areresponsive to ATE software in order to carry out the testing of the DUT.Included in the hardware resources for each board are memories (notshown) that store the test patterns, expected DUT results and thecaptured DUT results used for carrying out the method of the presentinvention.

With reference now to FIG. 5, the method of the present inventioninvolves steps to analyze and process the test information gathered fromthe DUT by the tester. The method is tailored to enable the tester toevaluate data from the DUT that is “non-deterministic”, or does notconform to rigid expected results. In other words, the method allows thetester to capture actual data from the DUT, compare it to expected data,and if no match occurs, carry out further processing to determine if thedevice still operates within acceptable parameters.

Further referring to FIG. 5, the method of the present invention lendsitself well as a modification to existing ATE software packages, such asthat known under the trademark Image™, licensed by Teradyne, Inc.,Boston, Mass., to users of its automatic test equipment. Generally, ATEsoftware compiles test patterns for application to the device-under-test(DUT), including expected results that are compared to the actualresults captured from the DUT. Modifying this general approach to enablethe tester to handle non-deterministic data involves first creating abus layout file, at step 100.

The bus layout file created at step 100 includes information describingthe DUT communications protocol bus architecture. For example, the fileincludes a parameter identifying how far out of order the actual DUToutput packet and/or control signals (collectively referred to as“entities”) can be sequenced with respect to the expected order withoutviolating the device operating specifications. This parameter may bereferred to as the device “complexity.” Additionally, the bus layoutfile includes pin and frame mapping data to identify DUT pins thatdefine the bus, and pins that represent bits on the bus. Further, theframe signal pin is also identified in the bus layout file.

Once the bus layout file is created, the expected pattern may becompiled, at step 102. As noted above, the expected pattern is asequence of packets and control signals that the tester uses to compareactual DUT output data against to determine data validity. This step issimilar to conventional compiling steps for ATE software, but includesthe capability of identifying both packets and control symbols in apattern file. This is accomplished by locating the entities in theexpected pattern, at step 104, and generating a list of the entities, atstep 106.

Each entity in the list includes information such as whether it is apacket or control signal, the “entity order” (its sequential ordernumber in the data sequence relative to other packets and controlsignals), its typeorder (sequential order number relative to otherpackets OR control signals), and its start address and end address inthe pattern memory (not shown).

Once the preliminary compiling and list generating steps are complete,one of potentially many tests may be performed on the DUT, at step 108.As generally described above, each test involves applying test waveformsto the device, and capturing the response data from the DUT. The teststep includes the initial comparison between the expected entities, andthe actual entities captured from the DUT during the test, and stored ina capture memory (not shown).

If the entire pattern of expected entities match up with the actualentities at the determination step 110, then the device is considered tohave passed the test, at step 112, and processing stops, at step 114.

However, if at the determination step 110 a fail is detected (a mismatchbetween an expected entity with an actual entity at a specific DUTcycle), then a modified “compare” step is performed that compares thecaptured entities against a list of valid expected entities, at step116.

The enhanced compare step, at step 116 of FIG. 5, is more fully shown inFIG. 6, and explained in more detail below. The step includes firstretrieving, at step 200, the captured actual data from the capturememory (not shown). Once the data is retrieved, a valid packet “window”is then defined, at step 202.

Defining the window, at step 202 involves accesssing the bus layout fileto determine the entity complexity (how far out of order the entity isallowed to be). The entity's “typeorder” is also considered (where theentity should be in relation to other entities of the same type). Inessence, these entity windows define the allowable range ofnon-determinism that each entity can have to still be considered validdata. The maximum number of valid entities in the window is defined bythe relationship:size=(2*complexity)−1In other words, the maximum size of the window is essentially twice theallowable “complexity” (the number of DUT subcircuits competing to sendan output to the single DUT communications port). Thus, if a particularentity was supposed to show up at a certain cycle (in the originalexpect pattern), it was actually valid if it occurred anywhere withinthe window defined above.

The boundaries of the window are determined by a comparison of the“typeorder” number to the entity's complexity. For instance, if theentity was expected as the first entity, then the window would not beable to extend into negative numbers. The window boundaries may beconveniently defined by identifying the typeorder number and ensuringthat C−1 (where C is the entity complexity) positions are available oneach side of the entity for the window. If the positions areunavailable, then the lower or upper boundary of the window is thestart/end of the entity data. For purposes of clarity, FIG. 7illustrates an example for a series of packet entities, with differentdefined windows depending on the TypeOrder (each with a complexity ofthree).

The captured entity is then compared to one of the expected entities inthe window, at step 204. If a match occurs at the determining step 206,then the method iterates, beginning with step 200, to retrieve the nextoriginally failing captured entity, and construct its window, at step202. If no match occurs at the determining step 206, then anotherdetermination is made, at step 207 whether the end of the window hasbeen reached (all of the entities in the window have been compared). Ifthe end of the window is reached, then the device fails, at step 208. Ifthe window still has uncompared entities, then the comparison step 204is reperformed with the next entity in the window.

If all of the captured entities match an entity within their respectivewindows, then the device is considered to have passed, at step 120 (FIG.5) and processing stops, at step 122. Otherwise, as noted above, thedevice fails, at step 124 (FIG. 5) with processing halted, at step 126.An expected entity that has already passed cannot be reconsidered aspart of a valid window. It will exist in the window, but not beconsidered for comparison

As noted above, the enhanced comparison step overrides conventional ATEsoftware by enabling it to handle non-deterministic data situations, asneeded, without wholesale modifications to the tester hardwareresources. Consequently, the method of the present invention may beconveniently employed in existing ATE systems with little additionalcost.

Those skilled in the art will recognize the many benefits and advantagesafforded by the present invention. Of significant importance is thethroughput improvement made possible by the capability of furtherdetermining the validity of non-deterministic data that originallyfailed the initial test comparison. By evaluating an entity's validitywithin a window of acceptable parameters, or range of acceptableoperating cycles, more acceptable devices will pass testing procedures.This correspondingly reduces the device manufacturers costs.

While the invention has been particularly shown and described withreference to the preferred embodiments thereof, it will be understood bythose skilled in the art that various changes in form and detail may bemade therein without departing from the spirit and scope of theinvention.

1. A method for testing semiconductor devices that outputnon-deterministic entity information, the method including the steps:generating test signals with a semiconductor tester; applying thegenerated test signals to the device-under-test; capturing actual outputentities from the DUT in response to the applied generated test signals;comparing the actual output entities to expected output entities andidentifying a fail condition where a comparison fails to match an actualoutput entity to an expected output entity; and if a failure isidentified in the comparing step, defining a window of valid expectedentities and comparing the failed actual output entity to the window ofvalid expected entities.
 2. A method according to claim 1 and furtherincluding the step: substituting the fail condition with a passcondition where further comparing the failed actual output entity to thewindow of valid expected entities leads to a match between the failedactual output entity and any one of the valid expected entities in thewindow.
 3. A method according to claim 1 wherein the generating testsignals includes: creating a bus layout file.
 4. A method according toclaim 3 wherein the creating a bus layout file includes: identifying thedevice complexity.
 5. A method according to claim 1 wherein the step ofgenerating test signals includes: producing a list of packet and controlentities.
 6. A method according to claim 1 wherein each entity comprisesa packet or control signal according to a serial or parallelcommunications protocol.
 7. A method according to claim 4 wherein thestep of defining a window includes: establishing a range of validentities for the actual entities to fall within based upon the devicecomplexity and typeorder.
 8. Automatic test equipment for testingsemiconductor devices that output non-deterministic entity information,the automatic test equipment including: means for generating testsignals; means for applying the generated test signals to thedevice-under-test; means for capturing actual output entities from theDUT in response to the applied generated test signals; means forcomparing the actual output entities to expected output entities andidentifying a fail condition where a comparison fails to match an actualoutput entity to an expected output entity; and if a failure isidentified in the comparing step, means for defining a window of validexpected entities and comparing the failed actual output entity to thewindow of valid expected entities.
 9. Automatic test equipment accordingto claim 8 and further including: means for substituting the failcondition with a pass condition where further comparing the failedactual output entity to the window of valid expected entities leads to amatch between the failed actual output entity and any one of the validexpected entities in the window.
 10. A computer-readable medium havingstored thereon sequences of instructions which, when executed, cause oneor more electronic systems to carry out the steps: generating testsignals with a semiconductor tester; applying the generated test signalsto the device-under-test; capturing actual output entities from the DUTin response to the applied generated test signals; comparing the actualoutput entities to expected output entities and identifying a failcondition where a comparison fails to match an actual output entity toan expected output entity; and if a failure is identified in thecomparing step, defining a window of valid expected entities andcomparing the failed actual output entity to the window of validexpected entities.